前文|也就是_浅谈SpringCloudGateway源码

篇首语：本文由编程笔记#小编为大家整理，主要介绍了浅谈Spring Cloud Gateway源码相关的知识，希望对你有一定的参考价值。

本文不谈Spring Cloud Gateway相关的使用&＃xff0c;仅梳理在微服务项目中&＃xff0c;在使用Spring Cloud Gateway做为服务网关后&＃xff0c;接收到请求后的大体执行流程。

文章目录

• 大致流程图
• 具体流程
• • 一、DispatcherHandler
  • 二、getHandler
  • • 1、getHandlerInternal
    • 2、lookupRoute
    • 3、RouteDefinitionRouteLocator.getRoutes()
    • 4、r.getPredicate().apply()
    • 5、AbstractRoutePredicateFactory&＃xff08;断言配置predicates&＃xff09;
    
    
  • 三、invokeHandler
  • • 1、FilteringWebHandler&＃xff08;过滤器配置filters&＃xff09;
    • 2、filter(exchange)
    
    
  
  

不难发现gateway的主体流程并不复杂&＃xff0c;换句话说&＃xff0c;gateway的源码不是特别难。唯一膈应的就是大量使用了jdk8的新特性&＃xff0c;调试代码极不方便。

流程图比较粗略&＃xff0c;具体细节可以往下看

一、DispatcherHandler

该组件可以类比于Spring MVC中的DispatcherServlet。这里不在赘述Spring MVC接收到一个请求之后的跳转逻辑&＃xff0c;如果对相关源码感兴趣的&＃xff0c;可以查看我之前关于Spring MVC源码的分析。

浅谈SpringMVC源码的SpringServletContainerInitializer的完整加载流程

浅谈SpringMVC源码的DispatcherServlet组件执行流程

我们都知道&＃xff0c;如果我们要使用Spring Cloud Gateway&＃xff0c;需要移除Sping MVC相关的依赖&＃xff0c;否则会出现依赖冲突。其本质是因为&＃xff0c;Spring Cloud Gateway中是使用WebFlux替代了常规的Spring MVC做为请求转发&＃xff0c;由于WebFlux是基于响应式编程&＃xff0c;所以在面对大量请求的时候&＃xff0c;性能是要明显优于Spring MVC的。

补充一点自己对技术相关的思考

以我一个毕业一年的Java开发从业者的角度看来&＃xff0c;很多中间级提升效率的底层逻辑都差不多。这里以一篇我曾经记录的IO模型说明为起点&＃xff1a;请不要再说NIO和多路复用IO是同一个东西了&＃xff08;内含BIO、NIO、多路复用、Netty、AIO案例测试代码&＃xff09; 。真的就有点万变不离其宗的味道。

我们熟知的高性能中间件&＃xff0c;如Redis、Netty&＃xff0c;包括我们这里说的WebFlux&＃xff0c;它们底层不都是Reactor模型嘛。都是摒弃传统的一条龙执行到底的策略&＃xff0c;使用基于事件响应的策略&＃xff0c;继而达到提高响应性能的效果。但是有一说一&＃xff0c;这种源码是真调试&＃xff0c;对初学者并不友好。

前文我说过该组件可以类比于Spring MVC中的DispatcherServlet&＃xff0c;所以不难发现该部分的代码逻辑风格大体相同

那么主要也就是两条路&＃xff0c;一条是getHandler&＃xff0c;一条是invokeHandler

二、getHandler

获取对应的处理器list&＃xff0c;然后依次对每一个处理器进行响应的判断&＃xff0c;要么返回一个empty&＃xff0c;要么就是原样返回

1、getHandlerInternal

由于我们是在学习gateway相关的源码&＃xff0c;所以可以直接跳转到gateway包下面的AbstractHandlerMapping抽象类的实现类中

该方法也可以主要分为3部分&＃xff1a;

1、完成相关的参数判断&＃xff0c;满足条件直接返回empty

2、调用lookupRoute方法&＃xff0c;完成具体逻辑&＃xff08;重点&＃xff09;

3、移除exchange中的GATEWAY_PREDICATE_ROUTE_ATTR标签&＃xff08;这个标签是lookupRoute方法中放进去的&＃xff09;

2、lookupRoute

该方法内部内部分为三部分&＃xff1a;

1、获取到所有的router信息&＃xff0c;也就是我们配置在yaml中的配置

2、执行apply方法&＃xff0c;完成路径相关的处理&＃xff08;我们想自己拼接相关的字符串&＃xff09;

3、其他的校验和日志打印

3、RouteDefinitionRouteLocator.getRoutes()

根据方法我们不难看出&＃xff0c;gateway的解析逻辑为&＃xff0c;将我们配置的每一组路由信息&＃xff0c;会封装为一个RouteDefinition对象&＃xff0c;然后调用convertToRoute方法&＃xff0c;转换为一个Route对象&＃xff0c;即就是我们的路由信息

获取解析后的配置信息的逻辑比较简单&＃xff0c;可以自行了解。前文的获取getRouteDefinitions也就会调用该方法&＃xff0c;即表示调用GatewayProperties类中的getRoutes方法。GatewayProperties想都不用想&＃xff0c;直接就是一个&＃64;ConfigurationProperties注解&＃xff0c;配置一个前缀&＃xff0c;借助Spring Boot的能力&＃xff0c;完成文件解析。

4、r.getPredicate().apply()

r即为route&＃xff0c;获取路由信息上配置的断言接口&＃xff0c;此处完成调用。用技术的角度来说&＃xff0c;就是初始化route对象的时候&＃xff0c;其中一个参数是函数式接口类型&＃xff0c;这里就会拿到对应的属性&＃xff0c;完成方法的调用。

具体有哪些类型的

5、AbstractRoutePredicateFactory&＃xff08;断言配置predicates&＃xff09;

这是gateway里面一个十分重要的扩展抽象类&＃xff0c;即第4点中的断言工厂具体有多少种&＃xff0c;如何使用&＃xff0c;可以参考官方文档。我认为功能就可以类比为一个Filter差不多

我们这里可以简单看一个比较简单的实现&＃xff1a;HeaderRoutePredicateFactory

1、首先获取我们的请求中的请求头&＃xff0c;封装为一个list

2、如果list为空&＃xff0c;或者和我们配置的断言工厂没有匹配的都会返回false。

三、invokeHandler

前文我们已经获取到了handlerMapping&＃xff0c;并且进行了相关的断言处理。接下来我们要真正的开始处理我们的请求了&＃xff0c;即调用handle方法。

这里和Spring MVC的代码写法类似

同样的&＃xff0c;我们这里直接跳转到gateway对应的类中进行具体的逻辑处理

1、FilteringWebHandler&＃xff08;过滤器配置filters&＃xff09;

这个类里面的代码就很简单了&＃xff0c;这里也出现了我们所熟知的GatewayFilter和GlobalFilter&＃xff0c;即一个是作用在具体的路由路径上&＃xff0c;一个是作用在所有的路由请求上。这两种不同类型接口放入一个list中&＃xff0c;使用了一个适配器模式&＃xff0c;这里就不再赘述&＃xff0c;可参考&＃xff1a;适配器模式&＃xff08;Gateway中GatewayFilter和GlobalFilter整合实现&＃xff09;

2、filter(exchange)

根据代码风格&＃xff0c;我们也可以明白&＃xff0c;该步骤完成的功能是把我们所有的Filter构建为一个责任链模式的调用形式&＃xff0c;然后完成对应的责任链的中逻辑。

这里具体会有哪些Filter就根据你自己的配置了。

• GatewayFilter则直接看具体的内部类实现。
• GlobalFilter的调用逻辑则是位于GatewayFilterAdapter类中&＃xff08;适配器包了一层&＃xff09;。这里的请求就包含了把请求发送到具体服务器的功能

相关的Filter则都是以&＃64;Bean的形式加入到了Spring的容器中

补充两张Filter的功能图&＃xff1a;